前一天我們認識了Design Pattern以及知道了為何要使用Design Pattern。而在介紹及使用Design Pattern之前，我們得先知道他的原則及類型。所以今天我們要介紹Design Pattern的原則以及分類。
關於Design Principle，相信大家上網查都可以查到五大基本原則SOLID。但隨著時代的進步，技術及理論也會跟著進步及更新。現在查Design Principle，可能會有五大原則、六大原則甚至是七大原則。這裡會讓大家先初步認識七個Design Principle並舉一些簡單的例子，接下來幾篇會再詳細介紹每個Principle的內容。
| 縮寫 | 名稱 | 翻譯年糕 |
|---|---|---|
| SRP | Single Responsibility Principle | 單一職責原則 |
| OCP | Open Closed Principle | 開閉原則 |
| LSP | Liskov Substitution Principle | 里氏替換原則 |
| ISP | Interface Segregation Principles | 介面隔離原則 |
| DIP | Dependency Inversion Principle | 依賴反轉原則 |
| CARP | Composite/Aggregate Reuse Principle | 合成/聚合複用原則 |
| LKP | Least Knowledge Principle | 最少知識原則 |
一個類別專注做一件事，不應該將不相關的功能放在同一個程式碼內，使整體程式碼中的每個部分都與自己實作的功能相關。比如說購物車內有確認訂購內容、確認訂購人資料以及付款。很明顯付款跟與其他兩者的功能不同，所以不應該放在同一組程式碼內。
系統需要被擴充時，應該藉由新增新的程式碼來擴充新功能，而非修改原本的程式碼來擴充新功能。如銀行付款系統，從以前金融卡、信用卡到現在電子支付的付款方式。每當增加新的付款方式，應該要新增的類別來實作，而不是在原本的程式碼內做新增。
子類別可以擴充套件父類別的功能,但不改變父類別原有的功能。如同老鷹跟企鵝都是鳥，但老鷹會飛，企鵝不會。若鳥類中有一個fly的方法，而企鵝繼承後卻不能使用，因為企鵝不會飛。所以要需要覆寫fly，而這樣就違反了此原則。應該再分成會飛的鳥及不會飛的鳥來替代覆寫。
類別不應該強迫依賴他們不使用的方法。一位資深工程師，他需要寫程式，也需要做報告。這是這間公司期待資深工程師所需要具備的技能。但一般工程師只會寫程式，並不會寫報告。所以應該要將技能分成工程技能及其他技能。讓對應的工程是去實作相對應的技能，而不是將他不會的事情強制依賴給他。
高層模組不應該依賴低層模組，兩者皆應依賴於抽象;抽象不應該依賴細節，細節應該依賴於抽象。高低層模組好比呼叫者與被呼叫者關係，細節就是抽象類的實作。拿剛剛舉的付款的例子：用信用卡付款，程式內不應該將信用卡綁死在付款方法內，而是應該寫一個抽象的付款方法提供信用卡實作，再將抽象類別放入付款內。如此一來未來增加付款項目便不需要更動付款行為的內部邏輯，只需要增加付款項目的實作。
在軟體開發中，一定會遇到套件重複使用的問題。而應該先考慮使用組合/聚合的方式，其次才是繼承。若要使用繼承，則須符合里氏替換原則。如汽車有汽油車及電動車，其中又有黑色及白色。若用繼承的方式會產生黑汽油車、白汽油車、黑電動車、白電動車。若再增加顏色，則類別會更多，耦合性會更高。所以應該將顏色抽出，這樣只需要選好車種後，再將顏色帶入，降低整體耦合及提高程式靈活性。
迪米特法則(Law of Demeter) 又稱最少知識原則(Least Knowledge Principle)。只與自己直接有關係的類別溝通。如同老師想要清點班級的人數，他只需要問班長現在班上有幾個人，不需要直接去班上一個一個看。
Design Pattern分類有兩種，一種是常見的分類，也就是根據使用目的來分，可分成創建型模式（Creational Patterns）、結構型模式（Structural Patterns）以及行為型模式（Behavioural Patterns）。而依照作用範圍來劃分的話，則可分成類別模式（Class Patterns）以及物件模式（Object Patterns）兩種。而這系列文會用一班常見的三種分類來區分介紹。
註：Object Patterns翻譯是對象模式，但個人覺得用物件講起來比較順。
創建型模式：如何建立物件，它的特點在於是將物件的建立與使用分開。
結構型模式：關注於整體最終的結構，如何將類別及物件通過繼承和組合，構建出更加複雜的結構。
行為型模式：類別與物件之間如何分職責以及合作完成單一物件無法獨立完成的任務。
類別模式：處理父類別與子類別間的關係，此關係藉由繼承建立，為靜態，在編譯時即確定。
物件模式：處理物件之間的關係，此關係藉由合成或聚合來實現，執行時可以變化，動態性高。
| Type | Creational Patterns | Structural Patterns | Behavioural Patterns |
|---|---|---|---|
| Class Patterns | Factory Method Pattern | Adapter Pattern | Template Pattern Interpreter Pattern |
| Object Patterns | Singleton Pattern Abstract Factory Pattern Builder Pattern Prototype Pattern | Bridge Pattern Composite Pattern Decorator Pattern Facade Pattern Flyweight Pattern Proxy Pattern | Chain of Responsibility Pattern Command Pattern Iterator Pattern Mediator Pattern Memento Pattern Observer Pattern State Pattern Strategy Pattern Visitor Pattern |
而其中的23種Design Pattern就會在後面的文章詳細介紹，就先不在這邊贅述。
iThome鐵人賽
看影片追技術